home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000061_peterd@expresso.cc.mcgill.ca _Wed Mar 11 19:04:39 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <peterd@expresso.cc.mcgill.ca>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA28995; Wed, 11 Mar 92 19:04:39 GMT+0100
  4. Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
  5.     id AA05278; Wed, 11 Mar 92 18:59:29 +0100
  6. Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  7.         id AA00781  (mail destined for timbl@nxoc01.cern.ch) on Wed, 11 Mar 92 12:45:46 -0500
  8. Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
  9.     id AA02532; Wed, 11 Mar 92 12:45:32 EST
  10. Message-Id: <9203111745.AA02532@expresso.cc.mcgill.ca>
  11. In-Reply-To: Tim Berners-Lee's message as of Mar 11, 12:07
  12. From: peterd@expresso.cc.mcgill.ca (Peter Deutsch)
  13. Date: Wed, 11 Mar 92 17:45:31 GMT-0:02
  14. In-Reply-To: Tim Berners-Lee's message as of Mar 11, 12:07
  15. X-Mailer: Mail User's Shell (6.5.6 6/30/89)
  16. To: Tim Berners-Lee <timbl@nxoc01.cern.ch>,
  17.         Larry Masinter <masinter@parc.xerox.com>
  18. Subject: Re: Draft: Universal Document Identifiers
  19. Cc: cni-arch@uccvma.bitnet, www-talk@nxoc01.cern.ch, wais-talk@think.com,
  20.         iafa@cc.mcgill.ca
  21.  
  22. > From timbl@nxoc01.cern.ch Wed Mar 11 06:03:54 1992
  23. > >> Peter Deutsch's message  <9203051920.AA14978@expresso.cc.mcgill.ca>
  24. > >> Actually, Mike Schwartz has suggested using CRC checksums,
  25. > 
  26. > > From: Larry Masinter <masinter@parc.xerox.com>
  27. > > You can do better than that by either:
  28. > > a) use a good digital signature (MD5 or Snefru or ...). [...]
  29. > > b) rely on something else that's unique, e.g., hostid + timestamp, ISO
  30. > > DFR's DORs, Object Identifiers, etc. 
  31. > 
  32. > > We've been using 256-bit UDSNs and are happy with the scheme. I'm
  33. > > hoping we'll have a writeup together before next week.
  34. > 
  35. > Peter, USDN is your term, so you decide what is and isn't one.
  36.  
  37. I want a UDSN to be something that lets me identify the
  38. contents of a file and compare the contents of multiple
  39. files to test for uniqueness. In the long run I'd also
  40. like them to permit me to identify contents across
  41. multiple encodings, but that's harder and I'm prepared to
  42. wait for that.
  43.  
  44. I wouldn't be so bold as to try and decide what makes a
  45. suitable UDSN but I hope that we can discuss the issue at
  46. IETF next week (since we will have so many of the players
  47. there) and arrive at some sort of consensus.
  48.  
  49. I can say what _I_ want them for, and hope that this is
  50. something that would be useful to enough other people that
  51. we can agree to deploy something soon. Certainly there are
  52. a number of candidates, and Larry has named some of the
  53. most likely. I think something that can be applied
  54. retroactively (MD5?) would be preferable to something like
  55. hostID and timestamp, which would be hard to retrofit to
  56. the existing archive collections.
  57.  
  58. > However, a UDI I define to be something you can use to get the object. .  .
  59. > .  .  . Knowing when you have a document that  
  60. > you have the right document is a different problem, but with a
  61. > good name space (like x500) you can do both operations.
  62.  
  63. I'm principally interested in UDSNs at this point to allow
  64. comparisions between multiple items (perhaps found in disparate
  65. environments). I don't see how the X.500 name space can
  66. help me here (unless I'm misunderstanding what you mean?).
  67. Certainly it seems that UDIs should help locate items.
  68. That seems to be their raison d'etre.
  69.  
  70.  
  71.                 - peterd
  72.  
  73. --